why does this have to maintain state and move around cursor jumps? if i'm understanding the purpose of this widget correctly couldn't you just do arithmetic to calculate a percentage of the window height and then call layout_element.padding?

The spacers are adjustable by changing their val, which changes the ratio of their size in relation to the other spacers.

ah, this is why. 🤔

The reason is that you need to do this after all of the other layout_elements have been rendered, so that you know how much space is left.

I suppose you could combine this into the padding element with a ratio key or something, but you would still need to store state somewhere to do things at the end.

I'm happy to change methodology if you would prefer a different setup (e.g. I wasn't 100% happy with the naming "spacer" but couldn't think of anything better).

well, as far as vim goes drawing blank lines at the end of an unmodifiable buffer is pretty pointless, but if you used a spacer in the middle then yeah you would need to go back and adjust the space drawn at the beginning

Yeh, I thought about the blank lines at the end being pointless, but I also thought that doing an extra check in the loop would make the implementation more confusing, and since it was doing no harm, I left it as is.

can we iterate over the layout before layout_element is called and stick any of the arithmetic needed in the state? should allow us to not have to move around cursor jumps

keeping rendering happening from top to bottom sequentially just makes the state space of the program easier to think about

I agree that rendering from top to bottom makes things easier to think about 👍

We would just need to be careful about calculating sizes of elements before we render them.
For example, if a user provides a function for a text element, should we evaluate the function in the sizing part or the rendering part?

It's probably doable, but would just need some careful thought.

@goolord
I've refactored stuff so that we only render in one pass, and we don't mess about with the cursor_jumps once they are calculated.
I need to sort out the merge conflicts, but this PR should now have the same functionality as before, with an easier to follow state space.

Any thoughts?

seems better, i will give this a closer look when i have time